객체 관계 매핑

3. 구현 및 작동 방식

ORM은 객체 지향 언어의 API를 통해 데이터베이스 조작 기능을 제공하며, 내부적으로 SQL 쿼리를 생성하여 실행한다.^[8]

스토리지 드라이버의 구현 세부 사항은 일반적으로 사용 중인 프로그래밍 언어의 API에 래핑되어, 더 간단하고 주변 코드의 패러다임에 더 부합하는 방식으로 스토리지 매체와 상호 작용하는 방법을 제공한다.

다음은 데이터베이스 엔진을 사용하여 SQL로 작성된 쿼리를 실행하는 간단한 예로, C# 코드로 작성되었다.

```csharp

var sql = "SELECT id, first_name, last_name, phone, birth_date, sex, age FROM persons WHERE id = 10";

var result = context.Persons.FromSqlRaw(sql).ToList();

var name = result[0]["first_name"];

```

반면, ORM 작업 API를 사용하면 언어의 기능을 자연스럽게 활용하는 코드를 작성할 수 있다.

```csharp

var person = repository.GetPerson(10);

var firstName = person.GetFirstName();

```

위의 사례에서는 저장소를 나타내는 객체와 해당 객체의 메서드를 사용한다. 다른 프레임워크는 아래 예와 같이 코드를 정적 메서드로 제공할 수 있지만, 객체 지향 시스템을 전혀 구현하지 않을 수도 있다. 종종 ORM이 주변 언어의 설계 원칙에 가장 잘 맞도록 패러다임을 선택한다.

```csharp

var person = Person.Get(10);

```

객체 지향 프로그래밍에서 데이터 관리 작업은 일반적으로 단순한 스칼라 값이 아닌 값을 갖는 객체를 조작하도록 구현된다. 예를 들어, 한 명의 인물에게 0개 이상의 전화번호와 0개 이상의 주소가 대응하는 주소록에서의 주소 검색을 생각해 보자. 객체 지향적인 구현에서는 "인물 객체"에 주소록의 내용을 저장하는 슬롯이 갖춰진 형태로 모델화된다. 슬롯으로는 이름, 전화번호 리스트(또는 배열), 주소 리스트가 있다. 전화번호 리스트는 "전화번호 객체"로 구성되며, 다른 것도 마찬가지로 대응하는 객체로 표현된다. 프로그래밍 언어에서는 어떤 인물의 주소록이 하나의 값으로 취급된다(예를 들어, 한 개의 변수로 참조된다). 이 객체에 대해 추천 전화번호를 반환하는 메서드, 집 전화번호를 반환하는 메서드 등 각종 메서드가 연관된다.

그러나 데이터베이스 언어 SQL을 사용한 일반적인 데이터베이스 제품에서는 저장하고 조작할 수 있는 것은 스칼라 값(정수, 문자열)뿐이며, 스칼라 값에 의한 표를 형성하고 있다.

프로그래머는 객체를 데이터베이스에 저장 가능한 단순한 값의 그룹으로 변환하거나, 프로그램을 데이터베이스에 맞춰 단순한 값만 다루도록 해야 한다. 객체 관계 매핑은 전자의 수법을 구현하는 것이다.

이 문제의 요점은 객체를 데이터베이스에 저장 가능한 형식으로 변환하고, 나중에 용이하게 검색할 수 있도록 하며, 동시에 객체끼리의 관계 특성을 유지하는 점이다. 이러한 객체를 영속적이라고 한다.

가장 일반적인 데이터베이스는 데이터베이스 언어 SQL을 사용한 관계형 데이터베이스이며, 이는 1990년대 객체 지향 프로그래밍의 융성 이전에 이미 일반화되었다. 관계형 데이터베이스는 테이블이라는 개념으로 데이터를 저장한다. 서로 다른 관계 (테이블)에 존재하는 데이터 간의 관련성은 선언적 제약 조건에 의해 표시되며, 구체적인 포인터나 링크는 존재하지 않는다. 객체 지향에서는 같은 데이터가 하나의 객체에 저장되지만, 관계형 데이터베이스에서는 필요에 따라 여러 관계(테이블)에 저장된다.

객체 관계 매핑의 구현은 체계적이고 예측 가능한 방식으로 테이블을 선택하고, 필요한 SQL을 생성한다.

객체 관계 매핑 개발에 드는 수고를 줄이기 위해 다양한 패키지가 제공되어 왔으며, 이는 매핑을 자동으로 수행하는 클래스들의 라이브러리 형태를 띤다. 데이터베이스 내의 관계(테이블) 목록을 제공하면 자동으로 요청을 매핑한다. 인물 객체에 전화번호를 문의하면 적절한 쿼리가 생성되어 전송되고, 결과가 직접 전화번호 객체에 저장되도록 프로그래밍된다.^[7]

프로그래머 입장에서 보면 시스템은 영속적인 객체 보관소처럼 보인다. 객체를 새로 생성하고 적절한 처리를 하면 최종적으로 데이터베이스에 자동으로 저장된다.

그러나 실제로는 그렇게 단순하지 않다. 모든 객체 관계 매핑(O/RM) 시스템이 전혀 보이지 않게 작동하는 것은 아니며, 어느 정도 데이터베이스를 의식하지 않을 수 없다. 게다가 변환 계층은 느리고 기능이 불충분한 경우도 있으며(특히 생성하는 SQL의 질적인 측면에서 문제가 많다), 결과적으로 프로그램의 성능이 저하되고 메모리를 더 소비한다.

여러 객체 관계 매핑(O/RM) 시스템이 개발되었지만, 그 시장에 미치는 영향은 다양했다. NeXT의 Enterprise Objects Framework(EOF)는 뛰어난 제품이었지만, OPENSTEP에서만 작동했기 때문에 시장에 미치는 영향은 거의 없었다. 이는 나중에 NeXT의 객체 지향 애플리케이션 서버 WebObjects에 통합되었다. 1997년 애플 컴퓨터(Apple Computer)는 NeXT를 인수했고, 동사의 전자 상거래 사이트인 .Mac 서비스와 iTunes Store에 EOF 기술이 사용되게 되었다. 애플은 EOF를 두 종류의 구현으로 제공하고 있다. 하나는 macOS에서 가동되는 Core Data이고, 다른 하나는 WebObjects 5.2의 Pure Java 구현이다. EOF에서 영감을 받아 개발된 것이 오픈 소스 Apache Cayenne이다. Cayenne은 EOF와 유사하며 [http://jcp.org/en/jsr/detail?id=220 JPA standard]를 준수한다.

다른 방법으로 RDF와 SPARQL이 있다. RDF는 주어-술어-목적어의 트리플에 의한 직렬화이며, RDF/XML은 그 XML 표현, SPARQL은 RDF용의 SQL적인 쿼리 언어이다. 이 트리플로 주고받을 수 있는 데이터베이스를 트리플 스토어(triplestore)라고 부른다.

그 후, Java 관련으로 새로운 유사한 시스템이 Java Data Objects(JDO)로 등장했다. EOF와는 달리 JDO는 표준 규격이며, 몇몇 벤더에서 구현한 것이 등장하고 있다. Enterprise JavaBeans 3.0(EJB3)도 비슷한 분야를 커버하고 있다. 두 시스템 사이에서 표준 규격으로서의 경쟁 상태가 발생했다. 그 외에도 Java 관련으로 자주 사용되는 객체 관계 매핑으로서 Hibernate가 있다.

웹 프레임워크 Ruby on Rails에서는 객체 관계 매핑이 중심적인 역할을 하고 있으며, Active Record의 디자인 패턴을 사용하여 제어된다. 마찬가지로 Perl의 Catalyst에서는 DBIx::Class 모듈이 같은 역할을 하고 있지만, 그 외에도 선택지가 존재한다.

3. 1. 전통적인 데이터 접근 기술과의 비교

4. 객체 지향 데이터베이스와의 비교

객체 지향 데이터베이스 관리 시스템(OODBMS)은 객체를 직접 저장하고 관리하므로 객체 관계 매핑(ORM)이 필요하지 않다. OODBMS는 객체 지향 값을 사용하여 작업하도록 특별히 설계되었기 때문에 데이터를 SQL 형식으로 변환할 필요가 없다. 데이터는 원래 객체 표현으로 저장되고 관계가 직접 표현되므로 결합 테이블 작업이 필요하지 않다.

OODBMS는 복잡한 객체 관계를 효율적으로 처리할 수 있지만, 임시 쿼리(ad-hoc query) 실행이 어렵다는 단점이 있다. 많은 프로그래머들은 SQL에 익숙하며, 대부분의 객체 지향 데이터베이스가 제한된 범위 내에서 SQL 쿼리를 처리할 수 있음에도 불구하고 OODBMS의 제한적인 쿼리 기능 때문에 ORM을 선호하는 경향이 있다.

5. 비판 및 과제

ORM 도구는 구현 코드에서 실제로 일어나는 일을 모호하게 만드는 높은 수준의 추상화를 가지는 단점이 있다. 또한 ORM 소프트웨어에 대한 과도한 의존은 잘못 설계된 데이터베이스를 생성하는 주요 요인으로 언급되기도 한다.^[9]

객체 지향 프로그래밍과 관계형 데이터베이스 간에는 여러 가지 어려움이 발생하는데, 이를 객체-관계 임피던스 불일치라고 부른다.^[4]

ORM은 미리 정의된 기능으로 제한되어 있으며, 모든 예외적인 경우나 데이터베이스 기능을 다루지 못할 수 있다. 이러한 제한을 완화하기 위해, Django ORM과 같이 사용자가 원시 쿼리를 작성할 수 있는 인터페이스를 제공하기도 한다.^[6]

실제로 모든 객체 관계 매핑(O/RM) 시스템이 완벽하게 작동하는 것은 아니다. 어느 정도 데이터베이스를 의식해야 하며, 변환 계층은 느리고 기능이 불충분한 경우도 있다. 특히 생성하는 SQL의 질적인 측면에서 문제가 많아 프로그램의 성능 저하 및 메모리 소비 증가를 유발하기도 한다.

객체 관계 매핑은 객체 지향과 관계형 모델의 임피던스 불일치 문제에 대한 대증 요법에 불과하다는 비판도 있다. 관계형 데이터베이스의 원칙에서 보면 객체 지향은 데이터 조작에 불충분하며, 패러다임 전체에 문제가 있다는 것이다. 현재 객체 관계 매핑의 매핑은 잘못되었으며, 올바르게는 타입 (도메인)과 객체를 대응시켜야 한다는 주장도 있다.

6. 한국의 ORM 현황

한국에서는 Java 기반의 Spring Framework와 MyBatis, JPA 구현체인 Hibernate 등이 널리 사용되고 있다. 전자정부 표준프레임워크는 MyBatis를 기반으로 한 데이터 접근 계층을 제공하며, 공공 부문에서 널리 사용된다. 최근에는 Python 기반의 Django ORM, SQLAlchemy 등도 인기를 얻고 있다.

7. 대안

데이터 액세스 객체(DAO) 디자인 패턴은 SQL 문을 추상화하고, 나머지 애플리케이션에 가벼운 객체 지향 인터페이스를 제공한다. 이는 모든 주요 데이터베이스에서 제공하는 기본 절차적 언어를 사용하며, SQL 문을 통해 클라이언트에서 호출할 수 있다.^[5]

캐시와 같은 데이터베이스는 SQL 접근이 내장되어 있어 객체 관계 매핑(ORM)이 필요하지 않다. 캐시는 임의의 객체 지향 프로그래밍 언어와 함께 사용할 수 있으며, 이때 외부 도구는 필요하지 않다.

객체 데이터베이스는 객체를 직접 저장하고 관리하므로 데이터 변환 과정이 필요 없다.

7. 1. SQL 기반 절차적 언어

7. 2. NoSQL 데이터베이스

참조

_[1] 웹사이트 What is Object/Relational Mapping? http://www.hibernate[...] JBOSS Hibernate 2022-01-27
_[2] 논문 Solving the Java Object Storage Problem https://www.computer[...] Computer 1998-11
_[3] 뉴스 Wrecking Your Database https://www.toolbox.[...] Computer 2009-08
_[4] 간행물 Object–Relational Mapping Revisited - A Quantitative Study on the Impact of Database Technology on O/R Mapping Strategies https://www.semantic[...] Hawaii International Conference on System Sciences (HICSS)
_[5] 웹사이트 Oracle PL/SQL Programming http://docstore.mik.[...] 1997-09
_[6] 웹사이트 Performing raw SQL queries https://docs.djangop[...] 2024-09-08
_[7] 웹사이트 Animation showing how an object-relational mapping utility works http://www.service-a[...]
_[8] 논문 Solving the Java Object Storage Problem https://www.computer[...] Computer 1998-11
_[9] 뉴스 Wrecking Your Database https://www.toolbox.[...] Computer 2009-08